Since this isn't mentioned explicitly in the linked bug reports, I have a couple questions:

1. What problems does it cause for this pseudo-header to be present?
2. Are there other pseudo-headers that should also be filtered out to avoid similar problems?

Oops! That should have been included in the fetch bug report.
:Status is an intentionally invalid HTTP header which lets the macro writer explicitly set the response code. It is also used internally to get the status code from the request processing out to the wrapper layer. It could use an optional, or similar data type, but exposing those to the macro writers would be a bit of a trick. By specification, invalid HTTP headers must not be returned to the client, so it must be stripped out before the headers are returned. If the response is wrapped in a javascript Response object (as the fetch API does), Response's constructor will throw an exception on invalid headers. Note this is different from undefined / extension headers (valid headers must not start with :).

The problem is the header filtering happens when the response body is received. If there is an exception thrown between when the header default values are set and the response body is received, the body-received function is not called, so the headers do not get filtered. When fetch then tries to handle the failed request, it chokes on the invalid header.

So to sum up:

1. It breaks the fetch API
2. No.

That said, I think it might still have a problem outside the fetch API on internal server errors. Probably need to refactor it slightly to always explicitly filter the headers without calling the body-received function.

Hm, nope, I can't see why the MTXMLHttpRequest::recv doesn't get called before the headers get retrieved. Especially given that the critical onreadystatechange call which triggers the javascript-side header processing happens after the headers should be handled.